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Abstract 
RFC 4944 defines the ESC dispatch type to allow additional dispatch 
octets in the 6LOWPAN header. The value of the ESC dispatch type was 
updated by RFC 6282; however, its usage was not defined in either RFC 
6282 or RFC 4944. This document updates RFC 4944 and RFC 6282 by 
defining the ESC extension octet code points and listing registration 
entries for known use cases at the time of writing of this document. 
Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc8066. 
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Les 


Introduction 


Section 5.1 of [RFC4944] defines the dispatch header and types. The 
ESC type is defined to use additional dispatch octets in the 6LOWPAN 
header. RFC 6282 modifies the value of the ESC dispatch type and 


that value is recorded in IANA registry [IANA-6LOWPAN]. However, the 
octets and usage following the ESC dispatch type are not defined in 
either [RFC4944] or [RFC6282]. In recent years with 6LOWPAN 


deployments, implementations and standards organizations have started 
using the ESC extension octets. This highlights the need for an 
updated IANA registration policy. 


This document defines the new "ESC Extension Types" registry and the 
ESC extension octets for future applications. In addition, this 
document records the ITU-T specification for ESC dispatch octet code 
points as an existing known usage. 


Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


Usage of ESC Dispatch Octets 


RFC 4944 [RFC4944] first introduces this "ESC" dispatch header type 
for extension of dispatch octets. RFC 6282 [RFC6282] subsequently 
modified its value to [01 000000]. 


This document specifies that the first octet following the ESC 
dispatch type be used for extension type (extended dispatch values). 
Subsequent octets are left unstructured for the specific use of the 
extension type: 


Ord. 2-3-4 S6-7 89-0) L234 56 e T 8D Oo 1 23 4 467 89. OL 
Hato to toto tatatatoto toto tatatatatitotite te tatatatitititotetotatat 
| ESC | ESC EXT Type | Extended Dispatch Payload 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++ 


Figure 1: Frame Format with ESC Dispatch Type 


ESC: The left-most octet is the ESC dispatch type containing 
01000000”. 


ESC Extension Type (EET): It is the first octet following the ESC 
dispatch type. Extension type defines the payload for the additional 
dispatch octets. The values are from 0 to 255. Values 0 and 255 are 
reserved for future use. The remaining values from 1 to 254 are 
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assigned by IANA. The EET values are similar to dispatch values in 
the 6LOWPAN header except they are preceded by the ESC dispatch type. 
Thus, ESC extension types and dispatch values are using orthogonal 
code spaces. Though not desirable, multiple ESC dispatch types MAY 
appear in a 6LOWPAN header. Section 3.1 describes how to handle an 
unknown ESC dispatch type. 


Extended Dispatch Payload (EDP): This part of the frame format must 
be defined by the corresponding extension type. A specification is 
required to define the usage of each extension type and its 
corresponding Extension Payload. For the sake of interoperability, 
specifications of extension octets MUST NOT redefine the existing ESC 
Extension Type codes. 


Section 5.1 of RFC 4944 indicates that the Extension Type field may 
contain additional dispatch values larger than 63, as corrected by 


[Err4359]. For the sake of interoperability, the new dispatch type 
(EET) MUST NOT modify the behavior of existing dispatch types 
[RFC4944]. 


3.1. Interaction with Other RFC 4944 Implementations 


It is expected that existing implementations of RFC 4944 are not 
capable of processing ESC extension data octets as defined in this 
document. However, implementers have to assume that an existing 
implementation that attempts to process an EET that is unknown to 
them will simply drop the packet or ignore the ESC dispatch octets. 


If an implementation following this document, during processing of 
the received packet, reaches an ESC dispatch type for which it does 
not understand the ESC Extension Type (EET) octets, it MUST drop that 
packet. However, it is important to clarify that a router node 
SHOULD forward a 6LOWPAN packet with the EET octets as long as it 
does not attempt to process any unknown ESC extension octets. 


Multiple ESC extension octets may appear in a packet. The ESC 
dispatch types can appear as the first, last, or middle dispatch 
octets. However, a packet will get dropped by any node that does not 
understand the EET at the beginning of the packet. Placing an EET 
toward the front of the packet has a greater probability of causing 
the packet to be dropped than placing the same EET later in the 
packet. Placement of an EET later in the packet increases the chance 
that a legacy device will recognize and successfully process some 
dispatch type [RFC4944] before the EET. In this case, the legacy 
device will ignore the EET instead of dropping the entire packet. 
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3.2. ESC Extension Octets Typical Sequence 


The sequence and order of ESC extension octets with respect to the 
6LOWPAN Mesh header and LOWPAN_IPHC header are described below. When 
the LOWPAN_IPHC dispatch type is present, ESC dispatch types MUST 
appear before the LOWPAN_IPHC dispatch type in order to maintain 
backward compatibility with Section 3.2 of RFC 6282. The following 
diagrams provide examples of ESC extension octet usages: 


A LoWPAN encapsulated IPv6é Header compressed packet: 
+------- +------ +-------- +-------- 4+----------------- +-------- + 


ESC | EET | EDP |Dispatch| LOWPAN_IPHC hdr | Payla | 
+------- +------ +-------- +-------- +----------------- +-------- + 


A LOWPAN_IPHC Header, Mesh header and an ESC extension octet: 
4+----- 4+----- 4+----- 4+----+------ 4+------- 4+--------------- 4+------ + 
|M typ| Mhdr| ESC | EET|EDP |Disptch|LOWPAN_IPHC hdr| Payld| 
4+----- 4+----- 4+----- 4+----+------ 4+------- 4+--------------- 4+------ + 
A Mesh header with ESC dispatch types: 

+------- +------- 4+----- 4+----- 4+------- + 

| M Typ | M Hdr | ESC | EET |EDP | 

4+------- 4+------- 4+----- +----- 4+------- + 


With Fragment header: 


Figure 2: A 6LOWPAN Packet with ESC Dispatch Types 
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3.3. ITU-T G.9903 ESC Type Usage 


The ESC dispatch type is used in [G3-PLC] to provide native mesh 


routing and bootstrapping functionalities. The ITU-T recommendation 
[G3-PLC] (see Section 9.4.2.3) defines commands that are formatted 
like ESC Extension Type fields. The command ID values are 0x01 to 
Ox1F. 


The frame format is defined as follows: 


0: A238) Abe OF B39 0 2S A 36 Pe BD) OTD 2 3A 3) 6. 890 
tata t ata tata ta tartar ta ta tata tata ta tata ta tata ta tata HH 
|o ïl ESC | Command ID | Command Payload 
tata ta tata tata tata ta +H HH 


Figure 3: G.9903 Frame Format with ESC Dispatch Type 
3.4. NALP and ESC Dispatch Types 


According to Section 5.1 of RFC 4944 [RFC4944], NALP dispatch octets 
are reserved for use as a kind of escape code for identification of 
non-6LOWPAN payloads. Since ESC dispatch types are part of 6LOWPAN 
dispatch types (extended), they are orthogonal to NALP octets. 


This document clarifies that NALP dispatch codes only provide an 
escape method for non-6LOWPAN payloads when they appear as the 
initial octet of a LOWPAN encapsulation, and that the potential 
meaning of their appearance in any other location is reserved for 
future use. 


4. IANA Considerations 


IANA has registered the ’ESC Extension Types’ values per the policy 
"Specification Required’ [RFC5226], following the same policy as in 
the IANA Considerations section of [RFC4944]. For each Extension 
Type (except the Reserved values), the specification MUST define 
corresponding Extended Dispatch Payload frame octets for the receiver 
implementation to read the ESC dispatch types in an interoperable 
fashion. 


Section 4.1 of [RFC5226] indicates that "Specification Required" 
calls for a Designated Expert review of the public specification 
requesting registration of the ESC Extension Type values. 


The allocation of code points should follow the guidelines on "Usage 
of ESC Dispatch Octets" (Section 3) and the typical example 
(Section 3.2) sections. ESC Extension Type code points MUST be used 
in conjunction with 6lo protocols following [RFC4944] or its 
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derivatives. The requesting document MUST specify how the ESC 
dispatch octets will be used along with 6LOWPAN headers in their use 
cases. 


The initial values for the ’ESC Extension Type’ fields are as 


follows: 

pirne D E podne + 
| Value | Description | Reference | 
pienen Pr toss aaa + 
| 0 | Reserved | This document | 
| | | | 
| 1-31 | Used by ITU-T G.9903 and G.9905 | ITU-T G.9903 &| 
| | Command IDs | ITU-T G.9905 | 
| | | | 
| aa Unassigned 

| 255 | Reserved | This document | 
+------- Se aa a aa lag Raa a ah a a R + 


Figure 4: Initial Values for the ESC Extension Types Registry 
5. Security Considerations 


There are no additional security threats due to the assignments of 
ESC dispatch type usage described in this document. Furthermore, 
this document forbids defining any extended dispatch values or 
extension types that modify the behavior of existing dispatch types. 
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